
 We have presented a technique for generating positive test-cases for sets of correlated SQL views. Our setting considers that a database instance constitutes a test-case for a view if the view computes at least one tuple with respect to the instance.
Our proposal is to reduce the problem of obtaining a test-case to a Constraint Satisfaction Problem over finite domains.
 The generated constraints  take into account primary and foreign key database constraints if they are defined in an SQL table definition statement.
 The work improves the proposal of \cite{flops2010} by introducing a  complete treatment of existential subqueries. In order to prove the correctness of the technique, a new operational semantics for SQL views without aggregates is introduced. The theoretical ideas have been implemented in a working prototype called STCG,  available at:

\begin{center}
 \url{https://gpd.sip.ucm.es/trac/gpd/wiki/GpdSystems/STCG}
\end{center}

The prototype takes a set of views and the name of a particular view $V$, and generates a positive test-case for $V$. It uses MiniZinc \cite{MiniZinc} as  constraint modeling language. The output is given in the form of a list of SQL \cod{insert} commands that create the database instance.

Although the framework presented is useful for many types of queries, including those defined by set operations and those queries including existential subqueries, it is only a first step since there are many useful SQL features still not supported by our tool.
As immediate future work, we plan the integration of aggregate subqueries. The theoretical problem was already addressed in \cite{flops2010}, and the implementation seems straightforward. It would also  be interesting to extend the SQL operational semantics to aggregates in order to prove the soundness of the proposal. Another limitation that must be solved is the inclusion of \cod{null} values, which is currently not supported. However, the main limitation of the tool, and thus the main goal for our future work, is to extend the data types allowed for SQL columns. Currently the type of table attributes is limited to \cod{integer}, and at least \cod{varchar} (that is, string types) are required in order to obtain a really applicable tool.

From the theoretical point of view it would be interesting to define the introduction of existential nested subqueries directly into ERA, thus replacing SOS by an enriched version of ERA. Another theoretical improvement would be  to determine formally the minimum number of rows necessary for ensuring that a positive test-case exists. Currently, it is the user who indicates the number of rows for each table, but we think that the size could be determined by automatically examining the SQL code.

